Subject: Answers to HPR questions from DCL

From: "Ray Bird" <[email-masked]>
Date: Wed, 7 Sep 94 14:08:53 EDT

The following contains answers to more questions about HPR from
Mathew Finlayson of DCL.  The answers are preceded by "***".

Ray and Lap

A few more questions and comments about the HPR specification.

- The Status segment contains an ASEQ field to enable a windowing protocol
  to be carried out between RTP endpoints.  Presumably this protocol is not
  used by HPR (since it is explicitly turned off in the description of the
  Connection Setup segment.  The spec should have a comment to this effect
  in the description of the ASEQ field.

 *** This field is now reserved, we'll add additional comment to the document.

- The description of the ARB Segment (A1.6.6) talks about FIELD1 for the
  RQ/REPLY message type being measured in KBits/sec rather than Milliseconds.

 *** Thanks, the error's been corrected.

- the descriptions of the control vectors in sections A.1.7.1, A.1.7.2,
  A.1.7.4, A.1.7.5, A.1.7.6 state that the length contains any padding
  necessary to force embedded control vectors to start on 4-byte boundary.
  Since these control vectors can contain no embedded control vectors
  this should be removed.

 *** Have added a section describing all the alignment and padding rules.
     This section also describes exactly what is contained in the length
     fields.  All CV and segment length field descriptions refer to this
     new section.

- Neither the HPR specification nor the RTP specification discuss what
  should be done if the BSN wraps.  I am assuming that I should treat it
  similarly to the situation when SYNC wraps.

 *** Yes, it should be treated similarly to SYNC wrap.  It does require
     handling of BSN wraps with gaps during selective retransmission.

- The Forward Route Information CV is passed back on a negative Route
  Setup reply - is this necessary?

 *** Yes.  In fact the rule now is: whenever an error is found, the CV35
     is inserted as the first CV and all other CVs remain exactly as
     they were (to help in debugging).

- Could you confirm that the Limited Resource liveness timer (carried on the
  Route Setup GDS) should be set to zero if the route contains no
  limited resource links?

 *** Yes, if the route does not contain any limited resource link, the
     field remains zero.

- How should the SHORT_REQ timer be initialized?  The endpoint which brings
  the connection up can, perhaps, rely on the accumlated transmission time to
  give it an estimate.  The listening endpoint doesn't receive this
  information

 *** The SHORT_REQ timer does not have to be accurately initialized
     since it will be adapted to the path after a few status requests
     (approximately 6 samples, see awp).  It is initialized to 1 second
     (i.e. a relatively large value).  It can be estimated based
     on the accumulated transmission time but this information does not
     include propagation delay so it must be accounted for.  The
     architecture specification chooses the former method to initialize
     this timer.

- Can you clarify connection termination in the error case (if an
  DISCONNECT(strongly or not strongly) is issued without COB exchange).  As
  far as I understand, if the DISCONNECT is not strongly, then the issuing
  side starts its dally timer but does not send any notification to its
  partner unless it receives a packet.  In this case it replies with a
  STATUS packet with the closed bit (and also the last message bit?) set.

  Is this correct?

 *** Your assumptions are correct.  However, to provide graceful
     termination, an RTP user sends its last message prior to
     issuing DISCONNECT; as a result, the local RTP sends a message with
     the LM and status request bits set to 1 to the partner and then
     waits for an ACK/status message from the partner for this message.
     The partner will reply and subsequently will send its last message
     (it has the option to send data even after it receives the LM.)
     The local RTP will reply with a status message.  The local RTP user
     can now issue DISCONNECT (strongly=no) and start the dally timer
     to make sure the reply message gets to the other end.  Subsequent
     messages sent by the local RTP have the LM bit set to 1 (because the
     last message was previously sent) and the Closed bit set to 1.

- What is the use of the RASAP indicator in HPR?  I'd originally thought that
  it should be used to decided whether to piggy-back the STATUS message, or
  to reply immediately with a dedicated packet, but the discussion in
  7.2.4.1.4 seems to quosh this theory - it suggests that the STATUS message
  should always be piggy-backed if there is data waiting to send.

 *** HPR always sets the RASAP indicator to 1 indicating that it wants
     STATUS immediately.  If the receiver has data ready to send it
     can piggyback the STATUS on it; if not, it sends the STATUS
     in a dedicated packet.

- Are you planning on including an FSM specifying the way that RTP Status
  negotiation works in the Approved Pages Draft?  I found this to be one of
  the hardest areas to work out in the current specifications, and
  probably one of the most likely areas for interoperability problems.

 *** No.  Perhaps in view of some of the answers to the above questions
     (e.g. RASAP always set to 1) this area is not so complex.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================